• Rename dynamic plugin toggle key from disabled to enabled in YAML configs
• Update Lightspeed and Orchestrator docs to match the new enabled: true/false convention
• Keep example override snippets consistent with current dynamic plugin configuration semantics

graph TD
  OP["Operator"] --> CFG["dynamic-plugins*.yaml"] --> LDR["Dynamic plugin loader"] --> PLG["Plugins active"]
  DOC["Docs (Lightspeed/Orchestrator)"] --> OP

Loading

The following are alternative approaches to this PR:

1. Dual-key compatibility (`enabled` + legacy `disabled`)

• ➕ Reduces breakage for existing user configs and downstream examples
• ➕ Allows gradual migration with clear precedence rules
• ➖ Requires parser/runtime support and additional tests
• ➖ Adds ambiguity if both keys are present without well-defined precedence

2. Migration guidance + validation

• ➕ Keeps runtime simple while helping users update safely
• ➕ Can catch misconfigurations early (schema validation / linting)
• ➖ Still requires users to manually migrate existing files
• ➖ Validation tooling may not exist or may add CI overhead

Recommendation: The PR’s approach (standardizing on enabled) is the right direction for clarity and consistency, especially in docs and shipped example configs. Ensure the underlying dynamic-plugin config consumer either already supports enabled or provides clear migration/compat messaging (and precedence rules if disabled remains accepted) to avoid surprising breakages.

Documentation (2) +7 / -7

working-with-lightspeed.mdAlign Lightspeed disable instructions with 'enabled: false' +3/-3

Align Lightspeed disable instructions with 'enabled: false'

• Updates the Lightspeed disablement instructions and YAML snippet to use 'enabled: false' instead of 'disabled: true'. This ensures documentation matches the updated dynamic plugin config format.

docs/lightspeed/working-with-lightspeed.md

README.mdUpdate Orchestrator README example to 'enabled: true' +4/-4

Update Orchestrator README example to 'enabled: true'

• Updates the README configuration snippet for Orchestrator-related plugins to use 'enabled: true'. Keeps documentation consistent with the dynamic plugin configuration key rename.

orchestrator/README.md

Other (3) +22 / -22

dynamic-plugins.override.example.yamlUpdate override example comments to use 'enabled' +10/-10

Update override example comments to use 'enabled'

• Replaces commented 'disabled: true/false' examples with the equivalent 'enabled: false/true' values. Keeps the sample override file aligned with the current dynamic plugin configuration convention.

configs/dynamic-plugins/dynamic-plugins.override.example.yaml

dynamic-plugins.yamlSwitch plugin toggles from 'disabled' to 'enabled' +8/-8

Switch plugin toggles from 'disabled' to 'enabled'

• Renames the per-plugin toggle key to 'enabled' throughout the primary dynamic plugin config. Preserves the prior behavior by inverting values where appropriate (e.g., previously 'disabled: true' becomes 'enabled: false').

configs/dynamic-plugins/dynamic-plugins.yaml

dynamic-plugins.yamlRename Orchestrator plugin toggles to 'enabled' +4/-4

Rename Orchestrator plugin toggles to 'enabled'

• Switches Orchestrator dynamic plugin configuration entries from 'disabled: false' to 'enabled: true'. Maintains the same activation behavior with the new key name.

orchestrator/configs/dynamic-plugins/dynamic-plugins.yaml

Description

orchestrator/configs/dynamic-plugins/dynamic-plugins.yaml still uses disabled: false while the
PR updates the Orchestrator README example and the primary dynamic-plugins config to the new
enabled: true/false key. This leaves two competing config formats in-repo and makes the README’s
“copy plugins from orchestrator/configs/…” instruction likely to produce an out-of-date override
snippet.

Code

orchestrator/README.md[R16-19]

  - package: 'oci://registry.access.redhat.com/rhdh/red-hat-developer-hub-backstage-plugin-orchestrator:{{inherit}}'
-    disabled: false
+    enabled: true
  - package: 'oci://registry.access.redhat.com/rhdh/red-hat-developer-hub-backstage-plugin-orchestrator-backend:{{inherit}}'
-    disabled: false
+    enabled: true

Relevance

⭐⭐⭐ High

Team historically enforces README/config consistency; accepted fixes updating referenced
orchestrator plugin snippets and config paths (PRs #183, #34).

PR-#183
PR-#34
PR-#164

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The PR changes the Orchestrator README example plugin entries to enabled: true and tells users to
copy the plugin list from orchestrator/configs/dynamic-plugins/dynamic-plugins.yaml, but that
referenced file still contains disabled: false entries. The main default dynamic plugins config
also now uses enabled: ..., reinforcing that the orchestrator template is the odd one out.

orchestrator/README.md[6-32]
orchestrator/configs/dynamic-plugins/dynamic-plugins.yaml[5-21]
configs/dynamic-plugins/dynamic-plugins.yaml[7-40]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
The repo is being migrated from `disabled: true/false` to `enabled: true/false` for dynamic plugin entries. After this PR, `orchestrator/configs/dynamic-plugins/dynamic-plugins.yaml` still uses `disabled: false`, but `orchestrator/README.md` instructs users to copy plugin entries from that file and shows examples using `enabled: true`.

### Issue Context
This creates an inconsistent and confusing Orchestrator onboarding path: users following the README to copy the plugin list will copy the older `disabled:` key instead of the new `enabled:` key used elsewhere in the repo.

### Fix Focus Areas
- orchestrator/configs/dynamic-plugins/dynamic-plugins.yaml[5-21]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools